The engine is changing how it publishes per-value documentation for a
schema's choice set, moving from an `x-enum-descriptions` map to a
positional `x-mergify-enum` array that also carries a display title and a
deprecation flag. Schema syncs land as direct pushes to main, so the docs
repo cannot assume both sides move together.

Introduce `readEnumChoices`, which tolerates every shape a synced schema
can be in during that migration: values as a flat `enum`, a `const`, or
the `anyOf` of branches a composed `Literal` produces, with the node — or
any single branch of it — either inline or behind a `$ref`. Hoisting
repeated enums into shared components is what removes the duplicated
blocks from the published schema, and a reader that followed only the
property node would silently render an empty table once that happens.

Three things the shape change makes possible that the map could not, and
which are handled explicitly because each fails silently:

- Metadata can sit on the referring node as a `$ref` sibling rather than
  on the target, which is how pydantic publishes an annotation for a
  hoisted type. Both are consulted, nearest first.
- A positional array can fall out of alignment with `enum` in a way a
  keyed map never could. A length mismatch is treated as unusable rather
  than shifting every description onto the wrong value.
- The two shapes can coexist on one node mid-migration, so they are
  merged rather than treated as alternatives.

Ref resolution uses the `jsonpointer` the sibling readers already use:
hand-decoding each segment raises `URIError` on a pointer containing a
stray `%`, which would break the never-throws contract this reader
depends on to degrade instead of failing the build.

The dequeue reason table moves onto it here; the batch status table is
written against it from the start in a later commit. Rendered output is
unchanged.

Part of MRGFY-8330

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Change-Id: Ie539de06bf3391eb4390333810cda6e8f131b1e6